U.S. patent application Ser. No. 10/816,217, filed Apr. 1, 2004, in the name of Nicholas A. J. Millington, and entitled “System and Method For Synchronizing Operations Among A Plurality Of Independently Clocked Digital Data Processing Devices,” (hereinafter referred to as the Millington application) describes an arrangement for synchronizing operations among a plurality of independently clocked digital data processing devices. More specifically, the application describes a network audio system comprising a plurality of devices, which are referred to as “zone players,” interconnected by a network. The zone players comprising the network audio system may be distributed throughout any of a number of types of establishments such as residences, office complexes, hotels, conference halls, amphitheaters or auditoriums, as well as many other types of establishments. The zone players can render items of media content that are obtained thereby or otherwise provided thereto in electronic form. In one particular embodiment, the media content is in the form of audio content. The audio content may be provided by any of a number of sources. For example, audio content may be provided by compact disk players, turntables, radio receivers connected to respective ones of the zone players and that provide audio content in analog and/or digital form. In addition, the audio content may be in the form of digital files that may be stored on storage devices, personal computers and the like that are connected to respective ones of the zone players. Furthermore, the audio content may be in the form of digital files that may be retrieved by the zone players over the network. In addition, the audio content may be in the form of streaming audio content that is distributed by a variety of sources over a wide area network such as the Internet that are generally referred to as “Internet radio” sources. As noted above, in addition to obtaining items of media content, the zone players also render the media content, and so each zone player can be connected to one or more transducers, which are typically referred to as speakers, to provide an audible program comprising a series of one or more items of audio content.
In the network audio system described in the Millington application, the zone players that are rendering audio information in synchrony are referred to as a “synchrony group.” The zone players comprising the synchrony group receive the audio information, as well as rendering timing information that enables them to render the audio information synchronously, from a common source, which is generally also a zone player in the network audio system. Under some circumstances, it may be desirable to hand off the responsibility of providing audio and rendering timing information from one zone player to another. This may occur if, for example, the zone player that is currently providing audio and rendering timing information to the synchrony group is a member of the synchrony group, but is to disengage from the synchrony group and render another audio program. If the audio information is in the form of files that are retrieved over, for example, the Internet, the handoff from one “handing-off” zone player to another “handed-off” zone player can be coordinated by having the handing-off zone player provide the handed-off zone player with several pieces of information. The handing-off zone player will provide the handed-off zone player with a list of the particular files that contain the audio information that is to be rendered by the synchrony group. The files may be identified by, for example, Uniform Resource Locators (URLs) that enable the files containing the respective items of audio content to be located over the Internet. In addition, the handing-off zone player can provide the handed-off zone player with the particular rendering timing information that it will assign to a particular unit of audio information, which is typically referred to as a “frame,” that is located at a particular offset into a particular file. Using that information, the handed-off zone player can, independently of the handing-off zone player, obtain the frames subsequent to the frame at the specified offset from that file, as well as from any subsequent files in the list provided by the handing-off zone player, and, since the differential between the times at which successive frames are to be rendered is generally constant, the handed-off zone player can also generate rendering timing information for the frames that follow the offset as well as for the audio information in the content files subsequent thereto in the list. Therefore, after the handoff occurs, the handed-off zone player can provide the audio and rendering timing information to the members of the synchrony group independently of the handing-off zone player, so that the zone players in the synchrony group will continue to render the audio information synchronously and without a discontinuity in the rendering.
While the above-described operations work satisfactorily if the content items are in the form of files, a problem arises, however, if a handoff is to occur in connection with the audio information that is to be supplied to the synchrony group is not in the form of files, but is instead in the form of streaming audio information. Audio programs in the form of streaming audio information are provided over the Internet by a number of sources, including, for example radio stations and networks that also transmit or broadcast audio programs over conventional AM and FM radio and satellite radio signals, as well as sources that distribute audio programs only over the Internet. As with audio information in the form of files, streaming audio information comprising an audio program also comprises a series of frames. On the other hand, unlike audio information that is in the form of files, streaming audio information does not have a “beginning point” from which an “offset” can be determined. Nor does streaming audio information have frame identifiers by which the individual frames of the audio program can be identified. When a device contacts a streaming audio information source, the source will begin providing frames of the audio information stream that it is also concurrently also providing to other devices that wish to render the source's audio program. After a device begins receiving frames comprising an audio information stream from the source, it will typically buffer a selected number of frames. After the device has buffered the selected number, it will begin rendering the program. The buffering is provided to accommodate the fact that the device may experience temporary delays in receiving frames comprising the audio program for a number of reasons, including network congestion.
As noted above, streaming audio information is not in a form such as files, and so, although the handing-off zone player can provide the handed-off zone player with a URL identifying the source that is providing the streaming audio information for the audio program when a handoff is to occur, the handing-off zone player would be unable to provide a marker, such as an offset into a file, or an identifier for a particular frame of the audio information stream, that the handed-off zone player can associate with a particular rendering timing information from the handing-offzone player. This problem is exacerbated by the fact that a streaming audio information source actually provides streaming audio information over the Internet to each of the devices that is receiving the information over what is effectively a separate audio information stream, even though all of the audio information streams that are provided to all of the devices represent the same audio program. Accordingly, even if the handing-off and handed-off zone players are receiving streaming audio information comprising the same audio program from the same source at the same time, the two zone players may not be receiving the same frames of the audio program at precisely the same time. Accordingly, if, during a handoff operation, the handed-off zone player were to determine the rendering timing information that is to be associated with a frame that it receives from the source based merely on the proximity in the time that it received the frame and the time that it received audio and rendering timing information from the handing-off zone player, after the handed-offzone player begins to provide audio and rendering timing information for the synchrony group and as the various other zone players comprising the synchrony group migrate over to the handed-off zone player during the handoff operations, there may be annoying glitches and discontinuities in the audio program as rendered by the synchrony group. Moreover, since generally the zone players comprising the synchrony group generally will not all migrate over to the handed-off zone player at precisely the same time, there maybe several annoying glitches and discontinuities. Moreover, during the handoff operation, the zone players comprising the synchrony group will not be rendering the program perfectly synchronously.